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1. Introduction 
World-Wide Web browsers are starting to appear on a variety of 
consumer electronic devices, such as television sets and television 
set-top boxes, which are capable of receiving television programming 
from either terrestrial broadcast, satellite broadcast, or cable. In 
this context there is a need to reference television broadcasts using 
the URI format described in [RFC 2396]. This document describes a 
widely-implemented URI scheme to refer to such broadcasts. 

2. Television URI 
The basic structure of a television URI is: 

tv:<broadcast> 

where broadcast is a description of the data source. The description 
takes the form of a DNS-style identifier for a particular broadcaster 


or television network. For example: 


tv:wgqed.org the WQED station 
tv:inbc.com the NBC network 
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3.1. Scheme-only form 


A simplest form of the "tv:" URI scheme is used to refer to the 
"current" or "default" channel: 


tv: 


This URI refers to whichever television broadcast is currently being 
received by the device. It is often used in combination with HTML 
content that is actually being broadcast along with the audio and 
video, where the meaning of "current broadcast" is quite unambiguous 
(because it is the broadcast along with which the content containing 
the URI was received). This is in fact the most common usage of the 
"tv:" scheme today, and is explicitly referenced by the recently 
published specification of the Advanced Television Enhancement Forum 
[ATVEF 1.1]. 


3.2 DNS-style identifiers 


Television broadcasts traditionally have been identified in a variety 
of ways. All terrestrial television broadcasters are assigned call 
signs (such as "KDKA" or "WOED") to identify their signal. These are 
generally assigned by national authorities (such as the Federal 
Communications Commission in the United States) and are world unique. 
The global namespace is managed by the International 
Telecommunications Union, which assigns portions to member countries 
(see [ITU RR]). 


Many modern television networks are not broadcasted over-the-air, but 


available only through cable or satellite subscriptions. The 
identifiers for these networks (such as the familiar "CNN" and "HBO") 
are not regulated at this time. In some countries, even over-the-air 


broadcasters use these sorts of identifiers, rather than call signs. 


Unfortunately, these two namespaces overlap, with most network 
identifiers also being valid call signs. Furthermore, network 
identifiers are not world unique, and many cases exist of name 
collisions. (For example, both the Australian Broadcast Corporation 
and the American Broadcasting Company identify themselves as "ABC".) 
In order to ensure uniqueness, the "tv:" scheme uses DNS-style 
identifiers for all broadcast streams. Because these build on the 
existing registration system for DNS hostname, all name collisions 
can be resolved through the existing DNS dispute resolution 
processes. 
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In the simplest form, domain names themselves are used as broadcast 


identifiers. For example: 
tv:abc.com the American Broadcast Company 
tv:abc.co.au the Australian Broadcast Corporation 


In some cases, networks have multiple broadcast streams that need to 
be distinguished. This is also handled in DNS style: 


tv:east.hbo.com HBO Fast 
tv:west.hbo.com HBO West 


It is important to note that these DNS-style identifiers need not 
match real hostnames; they should not be resolved to IP addresses 
using DNS. Thus, using the terms as defined in RFC 2396, the "tv:" 
scheme is a Uniform Resource Identifier and not a Uniform Resource 
Locator. 


In order to support these identifiers in a "tv:" URI, a receiver must 
implement a means to map known identifiers to frequencies. The nature 
of this map and the way in which it is used are currently browser- 
and device-specific and are beyond the scope of this document. In 
this way, the "tv:" scheme is somewhat analogous to the "news:" and 
"file:" schemes in [1]: it merely names a television broadcast signal 
but assumes that the local browser has some means for actually 
retrieving that signal on the local device. A variety of software 
systems currently provide device-specific mappings from such 
identifiers to specific channel numbers or directly to frequencies. 
These systems can be incorporated into television sets or set-top 
boxes to facilitate the interpretation of television URIs by the 
client device. 


3.3 Obsolete forms 


Previous drafts of this specification allowed broadcasts to be 
identified by channel numbers, such as "tv:4", and this form is 
currently supported by several independent platforms. The channel 
numbers generally correspond to tuning frequencies in the various 
national broadcast frequency standards; for example, "tv:4" in the 
United states would be found at 66 MHz. However, because this 
mapping of channel numbers to frequencies varies from country to 
country, this form is particularly ill-suited to use on the Internet. 


Previous drafts also allowed network identifiers and call signs to be 
used directly as broadcast identifiers, as in "tv:abc" and "tv:kron". 
These forms should not be used because of the name collision issues 
described in the previous section. 
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4. 


BNF for Television URIs 


The following is a formal specification for the new URIs: 


tvuri = "tv:" [ broadcast ] 

broadcast = dns-identifier 

dns-identifier = *( domainlabel "." ) toplabel [ "." ] 
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum 
toplabel = alpha | alpha *( alphanum | "-" ) alphanum 


The definitions of alpha and alphanum are from [RFC 2396]. 
Furthermore, the definition of dns-identifier is identical to the 
definition of hostname in RFC 2396, and is case-insensitive. 
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Security Considerations 


This new URI scheme is subject to the same security implications as 
the general URI scheme described in [RFC 2396]. It is possible that 
the mere act of viewing a television broadcast signal may cause costs 
to be incurred to the viewer in some instances (e.g., "pay-per-view" 
movies and events). Any software that uses this URI scheme to allow 
automatic tuning of a client device to a particular television 
broadcast signal should alert users before performing actions that 
may incur costs to the user. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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